The approaches described in this section are approaches that could be pursued, but not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated, it should not be assumed that any of the approaches described in this section qualify as prior art merely by virtue of their inclusion in this section.
An enterprise manager is a computer application or set of applications that manages targeted software and/or hardware in an enterprise system. In a typical implementation, the enterprise manager comprises collection agents, a management server, and a repository. Each agent monitors and collects data from a target host. The management server receives the collected data from the agents and aggregates the collected data into the repository. The management server may also comprise a user interface that allows a system administrator to configure the settings of the enterprise manager and view the status of the target software and hardware systems.
Upgrading an enterprise manager can be a time-consuming and resource-intensive activity given the typical scale and complexity of the system on which the enterprise manager is deployed. For example, there may be thousands of collection agents distributed across different network nodes in a variety of regions and offices. In order to install a product update, each of these agents may need to be replaced with a new agent that is compatible with the new features. This complexity can become particularly burdensome on the system administrator responsible for managing the upgrade process. The system administrator must ensure that all agents are updated and functioning correctly. In addition, the system administrator may need to schedule a significant chunk of time to perform the system upgrade.
One straightforward approach to performing an upgrade involves completely shutting down the currently executing enterprise manager before the new enterprise manager is deployed. During this shutdown period, the collection agents stop monitoring their targets and sending data to the management server until the new enterprise manager is installed and activated. In large-scale systems, this approach results in significant downtime, especially where the collection agents need to be replaced with new agents. Because the collection agents are temporarily inactive, the enterprise manager may suffer from substantial monitoring loss.
In another approach, the new enterprise system maintains backward compatibility with the pre-update agents. This approach may reduce downtime and monitoring loss incurred from installing the new management system. However, maintaining backward compatibility often involves significant development costs, especially when the next generation system involves complex changes or other significantly differences from the legacy system. In addition, this approach constrains the development process of the next generation system, which leads to sub-optimal design that can permanent affect the next generation's product release.